Should a TestFlight app be using compatible DRs with one from the App Store, too? Just trying to figure out the test parameters for making sure it works. Okay - I see now that the TestFlight version and my notarized "Indie" version appear to share the same permissions - at least for "Full Disk Access" and "Automation". That's great. And quite the relief. I obviously got fooled by the development signing. And the work-around I implemented for resetting the permissions is not really necessary.

(I had to relaunch Xcode to make it use the new profile I had created online)

Huh - Xcode even says "Provisioning Profile – None Required", for all my embedded tools. I had given some wrong information earlier, though: I get the errors only for the binary-only tools, but not for the embedded faceless BG app. Still, Xcode shows the same info under "Signing & Capabilities" for the binary-only tools and the embedded app bundle, yet the app bundle appears to be accepted by the binary-only tools are not. I can't figure this out.

And how do I even add a .provisionprofile to a binary? I know how to embed an Info.plist into a binary tool (using a special section) – do I do the same for the profile? Does a sample project exist that has a binary-only tool embedded so that I can look at how it's supposed to work? There are so many variables here that it's difficult to try all the combinations when I keep just getting the same rough error message every time after an upload. BTW, I also did the "Fix an app built with Xcode".

Quinn, I've now read the linked document. The part at the end is a bit confusing to me as it says that the embedded tools only need their own entitlements because of Sandboxing. But since my app isn't sandboxed, do I still need to do that to get the errors fixed? If so, do I need to create a new cert for each sub-bundleID, or can I use the same wildcard cert? And then I need to create a separate .provisionprofile for each tool, even though it uses the same wildcard cert?

Quinn, Yes, the app contains both binary-only tools and bundles such as a faceless background app. Each has its own bundle ID, of course, but all derive from the main app's "org.tempel.findanyfile". That's the correct way, isn't it? Does each of these embedded binaries now need their own entitlement file? Or do I need to add something to the main entitlement file, such as listing each of the sub-binaries' bundle IDs? BTW, my app is exempt from sandboxing (legacy MAS).

I am getting this error now, in late 2026, after switching from building my app with Xcode 13.4 to Xcode 27.1 (only in order to get the new macOS 26ff appearance - while I still need macOS 10.11 support for my bug fix releases). What bothers me most about this error msg is that it still uses placeholders like "${executable}" instead of filling them in. Is this ever getting looked at? Has no one filed a bug report about this in all these years?

My bad. I meant to write: "The LoginItems surely isn't it". Content/Library/LoginItems is only used in conjunction with SMAppService. But I need to use it with the classic addition to the old Login Items list in the System Prefs, and for that purpose, when adding it to the app's LoginItems, it has side effects. I don't know the details any more but I had a good reason not to place it there.

Which macOS version did this happen on? I am still getting them occasionally, e.g. on macOS 15.2 and 15.7.3 Also, it helps to post the information on https://openradar.me/ It seems that I never filed a bug report, though.

I don't think it's sandbox related because my app iClip has the same issue: If the app was launched from within /Applications, the Help isn't found ("The selected content is currently unavailable"), but once I move it into the App folder, even if I rename it, Help comes back. Also, I build my app not with Xcode but with Xojo from 2021, and the Info.plist contains no Xcode or SDK related entries.

It would be great if you would put a copy of the report on openradar.me and post the link here.

I suspect it's not a bug that would get fixed but rather a case of bad project configuration, and I just need to learn what the problem is on my end. That's why I now opened a DTS incident and hope it won't get rejected because you asked for a bug report instead. I hope that this allows for a more direct dialog (Radar entries have never led to a dialog but only a reponse "we think this is fixed, please confirm" reply at best).

Would you please file it also at https://openradar.appspot.com/ Thank you for the effort.

searchfs takes practically the same time searching for creation dates than it does for file names. searchfs now takes 13-15s on /System/Volumes/Data with about 1.5M files. I suspect the increased speed is due to the faster Mac I'm using now (M4 Mini). But the issue becomes less significant now with faster Macs. I used to wait a minute for a search on a decently full startup volume, and that was standing out quite much vs. the "few" seconds it took on High Sierra with HFS+.

I just like to add my appreciation for the fact that this API is still available in ObjC format and not Swift-only. Not sure if that was intentional or necessary, but I'm glad either way :)